COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	.REQUIRE "GOOD.PUB[D,LES]" SOURCE_FILE
C00011 ENDMK
C⊗;
.REQUIRE "GOOD.PUB[D,LES]" SOURCE_FILE;

.MEMO("Ralph Gorin, Dick Helliwell, Jeff Rubin, John McCarthy, Forest Baskett",
.Les Earnest,The Next Timesharing System)

%3References:%1

1.  L. Earnest, Request for BBN Pager, ARPAnet memo to S. Crocker, October 1973.

2.  R. Gorin, "Display Services", note dated 28 November 1973.

3.  R. Gorin, Tenex notes, in file BLAH.BLA[N,REG], dated 12 February 1974.

.skip 2
.turn on "←"
We decided to "switch to Tenex" some time ago and, last October, made a semi-formal
commitment to ARPA to do so within a year [Reference 1].  Of course, "switching to
Tenex" can mean a number of different things.  This note summarizes the situation
as I see it.

←%3How we got here.%1

Our decision to pick up the BBN Pager and Tenex was based primarily on the
following considerations.
.narrow 4,4
1.  The virtual memory scheme greatly simplifies program memory allocation.

2.  Multiple processes under one job are operationally useful.

3.  A substantial segment of the ARPAnet community is using Tenex, which opens
the way to software sharing (mostly "export" for us, which earns some Brownie
points) and load sharing  (also "export" for the forseeable future).

4.  Tenex supports BBN Lisp, which some people think is good for them, though
it clanks a lot.
.widen
We recognized some shortcomings and adaptation problems in Tenex that would
have to be remedied before we could use it.
.narrow 4,4
1.  It has no display service.  We need something at least equivalent in
performance to our current service.

2.  Its swapping and scheduling algorithms are apparently ill-suited to
our swapper and load.

3.  The file system would have to be modified to run Librascope and the
3330.

4.  Other peculiar processors and devices would have to be accomodated:
PDP-6 (XGP service only), PDP-11 system, audio AD/DA, etc.
.widen
There are some additional shortcomings that should be fixed if we pick up
Tenex, but we could live with them for awhile.
.narrow 4,4
5.  Files must be audited for each reload (probably 15 minutes or so of
CPU time for us).  The file system should have sufficient redundancy and
checking so that this is not necessary.

6.  Realtime mode on the PDP-10 is useful, though the
need for it should be reduced somewhat by the existence of the PDP-11 system.
.widen
There are some other features that we should add to whatever system we
are going to use.
.narrow 4,4
7.  A fancier display service is needed, including the "page editor" idea
and complete graphics support for remote displays with CPUs via
ARPAnet or phone line.

8.  A better file system is desirable, providing such things as invisible
subdirectories for editors, the ability to insert records in the middle
of a file, etc.
.widen

←%3Current Alternatives%1

Plausible alternatives open to us now are as follows.
.narrow 4,4
1.  Continue development of our existing Monitor, adding a Tenex compatibility
package (Yuk!) and some of the new features that we want.

2.  Pick up either the BBN or DEC version of Tenex, add features to meet
our minimum requirements, then start converting our user population while
adding the desirable features.

3.  Design a glorious new timesharing system with some degree of backward
compatibility to both our current system and Tenex, and offering a Tenex-style
TTY user interface for those who want it.
.widen

The effort required to execute any of these alternatives cannot be estimated
accurately, especially without pinning down the design features much more
accurately.  Even so, I will venture some crude guesses.

The first alternative looks extremely difficult because of a number of Tenex
features that have no counterparts in our system.  In practice, it would
probably be more work than writing a new system.

With three good full-time system programmers, a minimally modified Tenex
system could be put up in 9 months to a year and a rather stable system in
another 9 months.  (With the crew we have, it should take only slightly longer.)

To develop a new system would probably take two years for a minimum operational
system and another year of fancy work.

←%3What should we do?%1

I believe that our system programming group has sufficient talent to produce
a new system that is significantly better than Tenex.  Whether they have
sufficient stamina to see such a project through the long pull is not so clear.
If we want to go this way, we will have a sizable job convincing ARPA that
we should overthrow their "standard" system.  With the current list of desired
features [Reference 3], the argument is not very compelling.

As things stand, I think that we should patch Tenex, even though this will
force us to live with a few minor atrocities for the forseeable future.  In
particular, I suggest the development of an initial system that supports
the following in compatability mode:
.begin narrow 4,4; nofill
1)  local display service (DD & III) including a page editor,
2)  PDP-6 service for XGP,
3)  PDP-11 service,
4)  other local peripherals,
.end
but omits such things as pseudo-teletypes, spacewar mode, upper segments,
and old-style user interrupts.

Once this system works, tuning and reprogramming of swapping and scheduling
programs would be done until the system is capable of supporting the local
load.  At that point, our user community would shift to the new system.

The next step would be to rewrite the file system to overcome fixed directory
size limitations and the need for frequent audits and to add other new features,
such as invisible subfile directories.